The present invention relates to the field of networks of devices connected using wireless links, in particular those devices that use the Bluetooth technology. Specifically, the present invention pertains to a method and system for registering a service record for a legacy application running on a virtual serial port.
Computer systems and other types of consumer electronic devices are commonly linked to each other and to peripheral devices using a myriad of different types of cables and connectors. As these devices grow in number and variety, their cables and connectors can often become quite cumbersome to work with. Accordingly, efforts are underway to develop technologies allowing hardware connections to be replaced with wireless ones.
One such technology is the Bluetooth technology. Bluetooth is the code name for a technology specification for short-range radio links that will allow the many proprietary cables that connect devices to one another to be replaced with short-range radio links.
The Bluetooth technology is based on a high-performance, yet low-cost, integrated radio transceiver. For instance, Bluetooth transceivers built into both a cellular telephone and a laptop computer system would replace the cables used today to connect a laptop to a cellular telephone. Printers, personal digital assistants (palmtop computer systems, hand-held devices and the like), desktop computer systems, fax machines, keyboards, joysticks and virtually any other digital device can be part of a Bluetooth system. Bluetooth radio technology can also provide a universal bridge to existing data networks and a mechanism to form small private ad hoc groupings (xe2x80x9cscatternetsxe2x80x9d or xe2x80x9cpiconetsxe2x80x9d) of connected devices away from fixed network infrastructures.
One issue that arises with the introduction of Bluetooth technology is the treatment of xe2x80x9clegacy applications;xe2x80x9d that is, those applications developed before the advent of Bluetooth and still residing on a Bluetooth-enabled device. These legacy applications are predicated on the use of actual (physical) serial cables, such as RS232 or similar serial cables, to connect the server and client devices. However, as described above, the Bluetooth technology replaces such cables with wireless connections. To address the issue of legacy applications, the Bluetooth specification (xe2x80x9cSpecification of the Bluetooth System, Core,xe2x80x9d version 1.0B, dated Dec. 1, 1999, herein incorporated by reference as background) defines protocols and procedures that can be used by Bluetooth devices to emulate serial cables.
Prior Art FIG. 1A is a block diagram illustrating the protocol layers and applications residing on Bluetooth-enabled devices A 10 and B 20 in one embodiment. For Bluetooth-enabled devices, the protocol layers are described by the Bluetooth specification referenced above. In general, baseband 19 and 29 carry out baseband protocols and other low-level link routines, and logical Link Control and Adaptation Protocol (L2CAP) 18 and 28 support higher level protocol functions.
Because they pre-date Bluetooth, legacy applications 12 and 22 are not configured to implement Bluetooth procedures for setting up emulated serial cables. Accordingly, RFCOMM 16 and 26 provide a transport protocol for emulation of serial ports over L2CAP 18 and 28, respectively. Serial port emulation blocks 14 and 24 are the entities that emulate serial ports and/or provide an application program interface to legacy applications 12 and 22, respectively. Thus, legacy applications 12 and 22 can run on devices A 10 and B 20, respectively, and communicate using the xe2x80x9cvirtualxe2x80x9d serial ports as if there were a real serial cable connecting the devices.
It is expected that the number of Bluetooth devices will increase significantly, and that the number of services (e.g., applications) that can be provided over Bluetooth links will also increase significantly. To help users of Bluetooth devices sort through the increasing number of services and applications that will become available, procedures are being developed to standardize how services are to be located and identified on Bluetooth devices. These standards and procedures are described in the above-referenced Bluetooth specification and summarized below.
The protocol stack used by Bluetooth devices includes a Service Discovery Protocol (SDP) that is used to locate (discover) services and applications that are available on a Bluetooth-enabled device, or that are in the vicinity of such a device. SDP provides direct support for search inquiries by service class and/or service attributes, and also supports service browsing. Search inquiries by service class are for identifying whether a known service is available, and search inquiries by service attributes are used for identifying whether services having particular characteristics are available. Service browsing is used for general searches to identify, for example, what services of a particular type (e.g., news, reference, gaming, etc.) are available.
Service discovery can be initiated by either a master device or a slave device. Generally, in the context of service discovery and service use, the terms xe2x80x9cserverxe2x80x9d and xe2x80x9cclientxe2x80x9d are used. xe2x80x9cServerxe2x80x9d is used to refer to a device with services and applications waiting for a connection from a client device, and xe2x80x9cclientxe2x80x9d refers to a device that initiates (requests) a connection to the application or service. A server device is also sometimes called an xe2x80x9cacceptor,xe2x80x9d and a client device is also sometimes called an xe2x80x9cinitiator.xe2x80x9d
The Bluetooth service discovery process provides the means for client applications to discover the existence of services provided by server applications, as well as the attributes of those services. The attributes of a service are maintained by the server in a service record. The attributes of a service include the type or class of service offered, and the protocol information needed to utilize the service. Significantly, the attributes of a service should also include a service name, which is a text string containing a user-friendly (e.g., human-readable) name for the service.
An issue with regard to legacy applications (e.g., 12 and 22 of FIG. 1A) is that they are not able to participate in the Bluetooth service discovery process. As mentioned, legacy applications 12 and 22 pre-date Bluetooth, and thus are not configured for the Bluetooth service discovery process.
Regarding service records for legacy applications, the Bluetooth. specification (specifically, Section 3.1.3 of the Serial Port Profile) states: xe2x80x9cAll services/applications reachable through RFCOMM [that is, legacy applications] need to provide an SDP service record that includes the parameters necessary to reach the corresponding service/application . . . In order to support legacy applications running on serial ports, the service registration must be done by some helper-application, which is aiding the user in setting up the portxe2x80x9d (emphasis added).
Prior Art FIG. 1B is a table exemplifying a service record 50 for an available service or application, in particular for a legacy application. xe2x80x9cServiceClassIDListxe2x80x9d identifies the type of service (e.g., serial port) represented by the service record 50. The xe2x80x9cProtocolDescriptorListxe2x80x9d specifies the protocol stacks (e.g., L2CAP and RFCOMM) that may used for the service. The xe2x80x9cProtocolSpecificParameter0xe2x80x9d represents the RFCOMM server channel of the legacy application. The xe2x80x9cServiceNamexe2x80x9d is a text name displayable to and readable by a user.
The Bluetooth specification defines most of the values in service record 50 for a legacy application, with the notable exception of the service name (ServiceName). Other than the reference to xe2x80x9csome helper application,xe2x80x9d the Bluetooth specification provides no guidance regarding how the service name for the legacy application is to be provided for service record 50.
The service name represents an important piece of information, enabling a user to readily identify an application and distinguish it from other applications, in particular when browsing through the large number of services and applications expected to be available in a Bluetooth environment. Thus, it is desirable to have a standard approach for providing the service name for a legacy application, so that the legacy application is readily identifiable to the user, as well as to simplify the service discovery process for the user.
One solution is to display to the user a pop-up window (or other graphical user interface), allowing the user to enter information to complete service record 50 for each legacy application. However, this solution can be problematic if the user does not know or understand what information is needed for service record 50. This solution may also be time-consuming and inefficient when information for a large number of legacy applications needs to be entered.
Accordingly, what is needed is a system and/or method for providing service record information (in particular, the service name) for legacy applications resident on Bluetooth-enabled devices. What is also needed is a system and/or method that satisfies the above need and that is user-friendly and conveniently implemented. In addition, what is needed is a system and/or method that can satisfy the above needs and that is satisfactorily consistent with the Bluetooth specification. The present invention provides these advantages and others not specifically mentioned above but described in the sections to follow.
A method and device are described for providing a service record for an application (e.g., a legacy application) running on a virtual serial port of a device. The virtual serial port emulates a serial connection (e.g., a serial cable) for the legacy application. The virtual serial port for the legacy application is opened by a virtual serial port driver. In accordance with the present embodiment of the present invention, the virtual serial port driver also provides the service name of the legacy application.
In one embodiment, the virtual serial port driver derives the service name from the name of the legacy application. In another embodiment, the virtual serial port driver uses a default name associated with the legacy application.
In a preferred embodiment, the device is a Bluetooth-enabled device. In the Bluetooth embodiment, a RFCOMM channel is selected for the virtual serial port. In one embodiment, the RFCOMM channel number is included in the service name derived by the virtual serial port driver.
In another embodiment, the present invention pertains to a method for accessing a legacy application residing on one wireless transceiver device from another wireless transceiver device in a network of wireless devices (e.g., Bluetooth devices in a Bluetooth network). A wireless connection between the first wireless transceiver device and the second wireless transceiver device is established. A first virtual serial port on the first wireless transceiver device and a second virtual serial port on the second wireless transceiver device are opened by a first virtual serial port driver and a second virtual serial port driver, respectively. The first wireless transceiver device creates a service record corresponding to the legacy application. A service name for the legacy application is registered in the service record. In accordance with the present invention, the service name is provided by the first virtual serial port driver. The service record is used by the second wireless transceiver device to locate the legacy application, so that a communication path from the second wireless transceiver device to the legacy application can be established over the first and second virtual serial ports. For example, the service name can be displayed to the user who is using the second wireless transceiver device to browse through the services provided by the first wireless transceiver device in accordance with the Bluetooth Service Discovery Protocol.
Thus, in accordance with an embodiment of the present invention, the virtual serial port driver performs the additional function of automatically providing a service name for a legacy application. The present invention introduces a standard and efficient approach for providing the service name for a legacy application, so that the legacy application is readily identifiable to the user. In addition, the service discovery process for legacy applications is simplified for the user. Furthermore, the present invention is consistent with the Bluetooth specification.
These and other objects and advantages of the present invention will become obvious to those of ordinary skill in the art after having read the following detailed description of the preferred embodiments which are illustrated in the various drawing figures.